A Categorical Theory of Patches

When working with distant collaborators on the same files, one often uses a distributed version control system, which is a program tracking the history of files and helps importing modifications brought by others as patches. The implementation of such a system requires to handle lots of situations depending on the operations users have performed on files, and it is thus difficult to ensure that all the corner cases have been correctly addressed. Here, instead of verifying the implementation of such a system, we adopt a “converse” approach: we introduce a theoretical model, which is defined abstractly by the universal property that it should satisfy, and work out a concrete description of it. We begin by defining a category of files and patches, where the operation of merging the effect of two coinitial patches is defined by pushout. Since the category is not closed under pushouts (two patches can be incompatible), in order to still be able to represent and manipulate files in conflicting states, we investigate the free completion of the category of files under finite colimits, which preserves existing colimits, and provide an explicit description of this category. Finally, we introduce a formalization of repositories based on event structures and discuss various generalizations of the model. It is common nowadays, when working with distant collaborators on the same files (multiple authors writing an article together for instance), to use a program which will track the history of files and handle the operation of importing modifications of the other participants. This software, called a version control system (VCS), implements two main operations. When a user is happy with the changes it has brought to the files it can record those changes in a patch (a file coding the differences between the current version and the last recorded version) and commit them to a server, called a repository. The user can also update its current version of the file by importing new patches added by other users to the repository and applying the corresponding modifications to the files. The first implementations of VCS (such as CVS or subversion) were based on a central server acting as unique repository, but this architecture is often considered as too rigid: if the server fails or if there is no internet connection the VCS cannot be used, also people would like to be able to run their own local VCS in order to perform experiments, etc. This is why modern implementations are distributed and called DVCS (for instance git, mercurial or Darcs): any participant acts as a local repository and patches can be imported from repositories to repositories. One of the main difficulty brought by this decentralized approach is that there is no global notion of time since there is no reference server, and created patches are only partially ordered in time. For instance consider a repository with one file A and two users u1 and u2. Suppose that u1 modifies the file A into B by committing a patch f , which is then imported by u2, and then u1 and u2 concurrently modify the file B into C (resp. D) by committing a patch g (resp. h). The evolution of the file is depicted on the left and the partial ordering of patches on the right: